1. Field of Invention
The present invention presented herein relates to integrated circuits. More specifically, the present invention relates to integrated circuits that have test and debug ports and logic that requires built-in hardware security features and methods of operation to limit or restrict access and operation of some or all of the embedded registers, memories, instruments, circuits, or data accessible through the test and debug ports.
2. Description of Related Art
In general, in the descriptions that follow, the first occurrence of each special term of art that should be familiar to those skilled in the art of integrated circuits (“ICs”) and systems will be italicized. In addition, when a term that may be new or that may be used in a context that may be new, that term will be set forth in bold and at least one appropriate definition for that term will be provided. In addition, throughout this description, the terms assert and negate may be used when referring to the rendering of a signal, signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively, and the term toggle to indicate the logical inversion of a signal from one logical state to the other. Alternatively, the mutually exclusive boolean states may be referred to as logic_0 and logic_1. Of course, as is well known, consistent system operation can be obtained by reversing the logic sense of all such signals, such that signals described herein as logically true become logically false and vice versa. Furthermore, it is of no relevance in such systems which specific voltage levels are selected to represent each of the logic states.
Modern ICs are designed and manufactured today with many security concerns. In addition to hiding or protecting sensitive material that may be designed or stored within the IC—such as DVD codes, bank codes, and encryption codes—there is a concern that the IC itself, or some portion or function within the IC, may be reverse engineered, copied, or cloned. Once an IC is placed on a board or in an application, and then board or system level programming or operation begins, then the IC is part of a larger concern as sensitive operation data may pass through, be stored, or be processed by the IC—at this point, then actual physical tampering and electrical, mechanical, environmental, and emissions snooping may come into play; or the IC may be used as part of a denial of service (“DoS”) or destructive test by operating it in an unauthorized manner. There may be many different ways that an attacker can address the chip so as to find out information about the IC's structure, it's role within a system, and the data it stores or processes. Protecting the IC from these various attacks as a standalone device or as a device on a board or contained within a system, is known as its security requirement. Many modern integrated circuit devices have functional or operational security requirements that have been solved mostly with encryption solutions such as RSA and AES—any data processed and either stored or passed through the physical pins of the IC's package is encrypted such that it makes no sense to the investigator unless they have the encryption code, sequence, or algorithm.
However, there is an aspect of the security requirement of the IC device that is often overlooked—the test and debug ports. Test and debug ports—such as the 1149.1 Joint Test Action Group (“JTAG”) four pin (optional 5 pin) Test Access Port (“TAP”) connection to the JTAG Controller and its defined internal scan register architecture—often provides unobstructed access to registers, data, test (scan and Built In Self-Test (“BIST”)), and debug (assertion, breakpoint, trigger and tracing functions) within the chip. Other ports than just the JTAG are also considered test and debug ports, for example, the Serial Peripheral Interface (“SPI”), or the Inter-Integrated Circuit (“I2C”), or the Serial-Wire Debug (“SWD”) ports are all common in the industry. The fundamental tenets of test and debug—controllability, observability, accessibility, and traceability—are often at odds with the security requirement, and so test and debug are viewed as an unmanaged back door by those with security concerns. Test and debug often not only provides access to data, registers and functions within the IC that should remain hidden, but also provides access to functions that could be used to prevent the IC from operating normally, e.g., a DoS attack, or that could be used to damage or destroy the chip, e.g., a destructive-operation attack. The test and debug ports also present another problem—there is ready availability to inexpensive test and debug hardware and software to operate these standardized and pseudo-standardized ports. This makes the perceived backdoor an even greater security risk.
There are some common industry applied methods used to prevent the test and debug ports from being used for illicit or nefarious purposes—the most common one being the disabling of the test and/or debug port(s) completely by fusing off its connection to the package pins, e.g., creating an open circuit between the package pin and the on-silicon signal, while, for example, pulling the signal down to a logic_0 internally. The disabling operation, however, generally occurs after IC test has successfully completed and so all downstream use of the port after the IC is verified as being good and salable is no longer viable. This denies the board or system user of the IC from being able to access and operate the test and debug functions that were originally standardized to allow IC integration operations such as IC solder-down and interconnect testing and in-system software development.
It would be advantageous to allow the legal authorized user of the IC to take advantage of these functions that are normally accessible after the IC has been through its manufacturing test and product distribution stages, so what is needed is some form of security-managed access where the test and debug port and controller remain active, but have some form of authorization usage model. In addition, security-managed access has further restrictions placed upon it by the design and test organizations—it cannot come at a high premium of either impact to the IC's design budgets (silicon area, gates, power, routing, route congestion, pins, timing, timing closure); or impact to the IC's test and debug quality and costs (test development effort, test coverage, test time, debug data correctness, debug data tags, debug time, and ATE cost). These budget and cost restrictions make the sophisticated encryption solutions that are most commonly applied to the functional pathways, too expensive in silicon area, too slow in test time, and too complex for use on common automatic test equipment (“ATE”). Note that security-managed access associated with the test and debug ports also needs to have some form of metric to quantify the security protection in the same manner as the functional security can be rated. The most common measurement currently applied is “how long should it take to break the security with a common hardware setup or with a common attack setup or scenario?”